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PROCEDE. 



v v Le systeme de radiocommunication cellulaire a un re- 
seau d'acces radio (15) comportant des stations de base et 
un organe de controle (16) auquel est relie un reseau local 
sans fil (20). Pour controler I'acces d'un terminal bi-mode 
(1 8) au systeme cellulaire a travers le reseau local sans fil, 
on execute les etapes suivantes: authentifier le terminal 
aupres du systeme cellulaire par I'intermediaire du reseau 
d'acces radio; allouer au terminal un jeton d'authentification; 
transmettre le jeton alloue de I'organe de controle au termi- 
nal par I'intermediaire du reseau d'acces radio; transmettre 
le ieton alloue et un identifiant du terminal de I'organe de 
controle a un serveur d'authentification accessible par I in- 
termediaire du reseau sans fil; et authentifier le terminal 
aupres du reseau sans fil en verifiant que le terminal posse- 
de le jeton transmis au serveur d'authentification. 
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PROCgDE POUR CONTROLER L'ACCES A UN S YSTEME CELLULAIRE 
HF RADIOCOMMUNICATION A TRAVERS UN R ESEAU LOCAL SANS FIL, 
ET ORGANE DE CONITRQLE POUR LA MISE EN CEU VRE PU PROCEDE 

. La presente invention concerne les techniques d'acces aux reseaux 
5 cellulaires depuis des terminaux radio. Elle vise plus particulierement le 
controle d'acces a un ou plusieurs systemes cellulaires de radiocommunication 
a travers un reseau local sans fil, 

Des reseaux locaux sans fil, ou WLAN ("Wireless Local Area 
Networks"), permettent aujourd'hui aux utilisateurs de terminaux appropries de 
10 disposer d'acces a haut debit a des services de telecommunication. II a ete 
propose d'associer de tels reseaux locaux a des systemes cellulaires etendus, 
afin de procurer aux abonnes de ces systemes cellulaires une grande capacite 
de debit dans des zones determinees ("hot spots"). 

Ce genre dissociation peut concerner divers types de WLAN et divers 
15 types de systemes cellulaires. A des fins d'illustration et sans que ceci soit 
limitatif, on s'interessera plus particulierement dans la suite a des WLAN de 
type IEEE 802.11 normalises par I'lEEE ("Institute of Electrical and Electronics 
Engineers"), et a des systemes cellulaires de troisieme generation de type 
UMTS ("Universal Mobile Telecommunication System") normalises par 
20 I'organisation 3GPP ("3 rd Generation Partnership Project"). 

La plupart des systemes cellulaires actuels, notamment les systemes 
UMTS, comportent d'une part un reseau coeur et d'autre part un ou plusieurs 
reseau d'acces radio. Le reseau coeur comporte des commutateurs mailles 
entre eux, appeles GSN ("GPRS Support Nodes"), ainsi que divers serveurs 
25 utilises notamment pour la gestion des abonnes du systeme (HLR, "Home 
Location Register"). Le reseau d'acces le plus courant des systemes UMTS est 
appele UTRAN ("UMTS Terrestrial Radio Access Network"). II se compose 
d'organes de controle appeles RNC ("Radio Network Controller") et de stations 
de base appelees "nodes B" reparties sur la zone de couverture du reseau 
30 d'acces et controlees chacune par I'un des RNC. 

Pour associer une technologie WLAN a un tel systeme cellulaire, il a 
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ete propose un schema d'integration a couplage faible entre les deux 
technologies. De facon typique, il est alors prevu une passerelle entre le WLAN 
et un HLR du reseau cceur du systeme cellulaire. 

La presente invention se rapporte plutot a des schemas d'integration a 
5 couplage etroit entre les deux technologies, ce qui permet aux utilisateurs des 
stations IEEE 802.11 de beneficier d'une grande partie des services procures 
par Tinfrastructure cellulaire. 

La figure 1 montre une architecture que I'on peut obtenir lorsqu'on 
applique un tel schema d'integration. Les commutateurs du reseau cceur 10 
10 communiquent entre eux par une interface normalisee dite Gn, et avec le HLR 
11 par I'intermediaire d'une interface dite Gr. On distingue les GGSN 12 
("Gateway GSN") qui servent de passerelles avec des reseaux extemes 13 tels 
que I'lnternet par exemple, et les SGSN 14 ("Serving GSN") qui sont relies a 
I'UTRAN a travers une interface dite lu. 
15 L'UTRAN 15 comporte un certain nombre de RNC 16 qui sont chacun 

relies a un SGSN du reseau cceur a travers I'interface lu (un seul RNC est 
represents sur la figure 1). Chaque RNC controle un ou plusieurs node B 17 a 
travers une interface dite lub. L'interface radio entre un node B 1 7 et un 
terminal UMTS 18 (UE, "User Equipment") est appelee Uu. 

20 Dans le schema d'integration illustre par la figure 1 , le RNC 16 est en 

outre relie a un WLAN 20 par I'intermediaire d'un reseau route 21 base sur le 
protocole IP. Le WLAN 20 comporte un ou plusieurs point d'acces 22, appeles 
AP ("Access Point") dans la terminologie IEEE. S'il y a plusieurs AP 22, ils sont 
typiquement supervises par un systeme de distribution 23 pouvant prender la 
25 forme d'un controleur de point d'acces (APC. "Access Point Controller"). 

Un terminal bi-mode UMTS /IEEE 802.11 est capable de 
communiquer par radio avec un node B 1 7 mais aussi avec un AP 22. 

Ce schema de couplage etroit permet de reutiliser les concepts UMTS 
de qualite de service, de securite et de mobilite pour les utilisateurs accedant 
30 au systeme par I'intermediaire du WLAN 20. II permet egalement a ses 
utilisateurs d'acceder a tous les services UMTS, notamment de localisation. 
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Compte tenu du pare relativement important d'AP de type IEEE 802.11 
dej£ installes, il est souhaitable que le schema de couplage etroit impose un 
minimum d'exigences au niveau de ces AP. C'est la raison pour laquelle la pile 
de protocole UMTS sur Interface RNC/WLAN (appelee ici interface law) est 

5 avantageusement construite par dessus la pile UDP/IP habituelle dans les 
WLAN, comme illustre par la figure 2. 

La figure 2 montre des piles de protocole utilisees pour les echanges 
entre un UE bi-mode 18 et le RNC 16 par I'intermediaire du reseau local sans 
fil 20. A I'interieur du WLAN 20, la couche physique est conforme aux 

10 specifications IEEE 802.11 sur I'interface radio et, par exemple, aux 
specifications IEEE 802.3 sur Interface filaire entre TAP 22 et I'APC 23. Le 
protocole de couche liaison est LLC, tel que specifie dans la norme 
IEEE 802.2. La figure 2 montre egalement la couche de protocole IP utilisee 
pour router les informations entre le RNC 16 et le terminal 18 par 

15 I'intermediaire du WLAN 20. Dans I'exemple represents, cette couche IP est 
aussi incluse dans I'APC 23, qui constitue un routeur. L'APC, lorsqu'il est 
present, pourrait cependant jouer un simple role de passerelle de couche 2. Le 
protocole de couche transport utilise est UDP ("User Datagram Protocol 0 ). Les 
paquets UDP/IP servent alors a transporter des informations relevant de 

20 canaux logiques UMTS. 

Ainsi, tous les services UMTS relevant de la couche 2 ou plus sont 
disponibles pour un terminal mobile 18 accedant au systeme par Hntermediaire 
du WLAN 20. En particulier, des ports UDP specifiques du RNC 16 et du 
terminal 18 sont utilises pour des canaux dedies de trafic (DTCH, "Dedicated 

25 Trafic CHannel") ou de contr6le (DCCH, "Dedicated Control CHannel"), dont 
les blocs de transport sont construits et traites par une instance du protocole 
UMTS MAC-d ("Medium Access Control - dedicated channels"). D'autres ports 
UDP sont utilises pour les canaux communs UMTS, en particulier pour les 
canaux logiques descendants de type BCCH ("Broadcast Control CHannel") et 

30 PCCH ("Paging Control CHannel") et pour les canaux logiques montants et 
descendants de type CCCH ("Common Control CHannel"). 

Dans les reseaux IEEE 802.11 classiques, il existe deux modes de 



contr6le d'acces des stations a interface radio : 

- un mode en systeme ouvert, dans lequel les stations ne sont pas 
authentifiees : lorsqu'une station capte la balise IEEE 802.11 emise par 
un AP, elle emet une requete d'authentification a laquelle TAP repond 
toujours positivement avant que la station s'associe a TAP; 

- un mode securise dans lequel le WLAN s'assure que la station detient 
une cle partagee pour I'authentifier et lui permettre de s'associer. 

Dans un schema d'integration de la technologie WLAN a un systeme 
cellulaire etendu, avec des abonnes en itinerance ("reamers"), il n'est pas 
realiste de faire partager une cle secrete a tous les abonnes du systeme 
cellulaire susceptibles d'y acceder par I'intermediaire d'un WLAN determine. II 
est done naturel de fonctionner en systeme ouvert au niveau du WLAN et 
d'assurer I'authentification des terminaux au sein du systeme cellulaire. Mais 
ceci pose un certain nombre de d'rfficultes. 

Tout d'abord, les operateurs UMTS proposant des acces WLAN 
souhaitent typiquement restreindre Taccds en mode IEEE 802.11 aux seuls 
clients potentiels, e'est-a-dire aux utilisateurs ayant des terminaux bi-mode 
WLAN /UMTS. En particulier, il est souhaitable de filtrer les stations 
IEEE 802.11 qui ne sont pas compatibles UMTS. Cependant, lorsque le WLAN 
fonctionne en systeme ouvert, toute station IEEE 802.11 est capable de 
s'associer aupr§s d'un AP et d'obtenir une adresse IP auprds d f un serveur 
d^llocation dynamique d'adresses, en general selon le protocole DHCP 
("Dynamic Host Configuration Protocol"). Meme si les stations non compatibles 
UMTS ne peuvent pas aller plus loin et acceder au RNC, il en resulte une 
consommation de ressources inappropriee dans le WLAN, notamment en 
termes d'adressage IP. 

De plus, il serait relativement facile pour une personne malveillante 
d'implementer la pile de protocole UMTS a partir de la couche MAC dans une 
station IEEE 802.11. Une station ainsi bricolee pourrait aisement etablir une 
connexion du protocole RRC ("Radio Resource Control") avec le RNC 16 puis 
dinger des requetes de service repetitives vers le reseau coeur 10. 

En outre, il se peut que plusieurs zones desservies par des WLAN 
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IEEE 802.11 se chevauchent. Dans un tel cas, il est souhaitable de pouvoir 
indiquer au terminal aupres de quel(s) point(s) d'acces il devrait s'associer. 

II se peut egalement qu'un meme WLAN 20 soit interface avec des 
RNC appartenant a des systemes cellulaires d'operateurs differents. Dans ce 
cas, il est judicieux de pouvoir designer au terminal le RNC avec lequel il 
convient d'etablir la connexion RRC. 

Comme le canal BCCH portant les informations systeme utiles aux 
echanges avec Infrastructure UMTS est un canal de diffusion, I'adresse IP de 
destination que specifie le RNC dans les datagrammes transportant ces 
informations BCCH doit etre reconnue par les terminaux comme etant une 
adresse de diffusion. Pour cela, on utilise typiquement I'adresse IP de 
"diffusion limitee" (1111 ... 111). Cependant, les datagrammes envoyes a cette 
adresse ne sont diffuses que dans le voisinage immediat de I'emetteur. En 
consequence, s'il se trouve que le RNC n'appartient pas au meme sous-reseau 
IP que les AP, le RNC doit plutot utiliser une adresse de diffusion a I'interieur 
du sous-reseau IP dont releve le ou les AP pertinents afin d'atteindre I'interface 
radio, c'est-a-dire une adresse IP ayant le format: (< IP Subnet Prefix > 
111 ... 111). Mais ^utilisation d'une adresse de diffusion dans un sous-reseau 
IP cree un autre probleme. Etant donne que le terminal 18 n'a generalement 
pas d'adresse IP predefinie (il en obtient une au moyen d'une transaction 
DHCP), il ne connaTt pas le prefixe de sous-reseau IP (IP Subnet Prefix) de 
sorte qu'il peut §tre incapable de detecter I'adresse IP de diffusion et done de 
recevoirles informations systeme UMTS. 

En 2001, I'lEEE a publie la norme IEEE 802.1X qui traite le contrdle 
d'acces a des reseaux locaux en ameliorant I'authentification des terminaux au 
moyen d'un serveur centralise. Cette norme est applicable a tous les reseaux 
locaux de la serie 802, notamment IEEE 802.3, IEEE 802.5 et IEEE 802.11. 
L'authentification IEEE 802. 1X est basee sur un secret que I'usager partage 
avec le serveur et non avec I'AP. Les messages d'authentification sont 
conformes a un protocole EAP ("Extensible Authentication Protocol") et 
transports dans des frames EAPOL ("EAP Over LAN") sur I'interface radio et, 
par exemple, dans des trames RADIUS sur le reseau filaire. 
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Un but de la presente invention est de faciliter le controle d'acces des 
terminaux bi-modes a un systeme cellulaire de radiocommunication a travers 
un reseau local sans fil, en limitant I'incidence des probtemes exposes ci- 
dessus. 

5 L'invention propose ainsi un procede pour contrSler I'acces a au moins 

un systeme cellulaire de radiocommunication a travers un reseau local sans fil, 
le systeme cellulaire ayant un reseau d'acces radio comportant des stations de 
base et un organe de contrdle auquel est relie ledit reseau sans fil. Selon 
l'invention, le procede comprend les etapes suivantes: 

10 - authentifier un terminal aupr6s du systeme cellulaire par I'intermediaire 

du reseau d'acces radio; 

- allouer audit terminal un jeton d'authentificatiqn; 

- transmettre le jeton alloue de I'organe de controle au terminal par 
I'intermediaire du reseau d'acces radio; 

15 - transmettre le jeton alloue et un identifiant du terminal de I'organe de 

controle a un serveur d'authentification accessible par I'intermediaire 
dudit reseau sans fil; et 

- authentifier le terminal aupres du reseau sans fil en verifiant que le 
terminal possede le jeton transmis audit serveur d'authentification. 

20 Un terminal s'entend ici comme un equipement d'usager capable de 

communiquer avec un systeme cellulaire, et aussi avec un reseau local sans fil. 
La plupart des systemes actuels considerent des terminaux form6s en 
associant un module d'identite d'abonne (SIM, "Subscriber Identity Module") a 
un appareil non specifique d'un abonnement. Le cas le plus representatif est 

25 alors celui ou Tauthentification porte sur I'abonnement, c'est-a-dire qu'elle met 
en jeu le SIM. Selon les methodes employees, Tauthentification peut 
eventuellement requerir la saisie d'un code secret ou d'un mot de passe de la 
part de Tusager. On peut aussi envisager que Tauthentification porte sur 
I'appareil, voire conjointement sur Tappareil et sur le SIM. D'autre part, 

30 I'authentification pourrait aussi porter sur des terminaux ne possedant pas la 
notion de SIM. 

Certains des parametres essentiels £ I'acces d'un terminal par 
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I'intermediaire d'un WLAN ne sont fournis a ce terminal qu'apres 
authentification auprds du systeme cellulaire. L'authentification WLAN n'est pas 
assuree exclusivement au niveau des AP, mais fait intervenir un serveur 
d'authentification accessible des terminaux par le WLAN et qui regoit les 
5 informations utiles de I'organe de contr6le. Dans le cas typique ou le WLAN est 
de technologie IEEE 802.11, cette authentification peut etre effectuee en mode 
IEEE 802.1X. 

Dans une realisation simple, le jeton d'authentification est utilise 
comme un mot de passe temporaire, dont la validite est couplee avec un 

10 identifiant d'usager temporaire. Dans une autre realisation, le jeton est utilise 
comme une clef de chiffrement temporaire, avec laquelle le terminal chiffre un 
challenge propose par le serveur. L'authentification peut aussi §tre mutuelle, 
c'est-a-dire que non seulement le serveur authentifie le terminal, mais aussi le 
terminal est capable d'authentifier le serveur, afin d'eviter de se raccorder & un 

15 eventuel WLAN malveillant. Par "jeton d'authentification", on entend ainsi un 
ensemble de parametres d'authent'rfication (mot de passe, clef de chiffrement 
temporaire, etc.) suivant le protocole d'authentification utilise. Comme le 
standard IEEE802.1X, Pinvention n'est pas limitee quant aux protocoles 
d'authentification. 

20 Dans une realisation de Tinvention, Tallocation du jeton 

d'authentification est effectuee par I'organe de controle. Dans un certain 
nombre de systemes cellulaires, tels que TUMTS, Techange initial entre le 
terminal et Torgane de controle (RNC) comporte la transmission par le terminal 
d'une liste de caracteristiques de celui-ci. Dans le cas d'un terminal bi-mode 

25 UMTS /WLAN, ces caracteristiques comprennent I'indication de ce caractere 
bi-mode. Uallocation du jeton d'authentification par le RNC peut alors etre 
conditionnee par le fait que la liste transmise par le terminal indique une telle 
capacite bi-mode. 

L'organe de contrfile transmet avantageusement le jeton 
30 d'authentification au terminal avec de reformation d'identification se rapportant 
au reseau local sans fil. Ceci permet au terminal de savoir auprfes de quel 
WLAN il est habilite a s'associer. Cette information d'identification peut §tre 
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selectionnee par I'organe de controle sur la base d'une localisation du terminal 
dans le reseau d'acces radio. 

Cette localisation resulte par exemple de la station de base du reseau 
d'accds radio par I'intermediaire de laquelle s'etablit le dialogue terminal / 
5 organe de controle. Certains systemes cellulaires, par exemple I'UMTS, offrent 
des techniques de localisation du terminal fonctionnant avec une precision 
meilleure que la granularity d'une cellule. Une de ces techniques repose sur 
1'utilisation du GPS ("Global Positioning System"); auquel cas la precision de la 
localisation est de quelques metres. 

10 Lorsque le reseau local sans fil est relie 3 I'organe de controle & travers 

un reseau IP, le jeton d'authentification est avantageusement transmis au 
terminal avec de reformation d'adressage dans ce reseau IP. Cette 
information d'adressage peut avantageusement comporter : 

- une adresse de diffusion de sous-reseau IP employee par I'organe de 
15 contr6le pour diffuser des informations systeme par I'intermediaire du 

WLAN; 

- une adresse IP du serveur d'authentification dans le reseau IP; 

- I'adresse IP de I'organe de controle. 

Ces differentes informations d'adressage permettent d'obtenir une tr6s 
20 grande souplesse de mise en oeuvre du couplage etroit entre un ou plusieurs 
systemes cellulaires et un ou plusieurs WLAN. 

Un autre aspect de la presente invention se rapporte a un organe de 
controle pour un reseau d'acces radio d'un systeme cellulaire de 
radiocommunication, comprenant: 
25 - des moyens d'interface avec au moins une station de base du systeme 

cellulaire; 

- des moyens d'interface avec un reseau local sans fil; 

- des moyens d'allocation d f un jeton d f authentification a un terminal 
authentifie aupr^s du systeme cellulaire par Pintermediaire du reseau 

30 d^cces radio; 

- des moyens de transmission au terminal du jeton alloue par 
Tintermediaire du reseau d'accds radio; et 
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- des moyens de transmission du jeton alloue et d'un identifiant du terminal 
a un serveur d'authentification accessible par Tintermediaire dudit reseau 
sans fil, de telle sorte que le terminal soit authentifie aupr^s du reseau 
sans fil par verification de ce que le terminal possede le jeton transmis 

5 audit serveur d'authentification. 

D'autres particularites et avantages de la presente invention 
apparaTtront dans la description ci-apr6s d'exemples de realisation non 
limitatifs, en reference aux dessins annexes, dans lesquels : 

- la figure 1, precedemment commentee, est un schema d'ensemble d'un 
10 systeme UMTS auquel on a integre un WLAN selon un schema de 

couplage etroit; 

- la figure 2, precedemment commentee, est un diagramme montrant des 
piles de protocoles utilisees pour I'acc&s au systeme UMTS a travers le 
WLAN; 

15 - la figure 3 est un schema synoptique montrant diverses entites d'un 

reseau IP utilise entre le WLAN a un ou plusieurs systemes UMTS; et 

- les figures 4A et 4B sont des diagrammes illustrant des exemples 
d'echanges de messages intervenant conformement a I'invention pour 
controler Tacces d'un terminal bi-mode au systeme illustre par les figures 

20 1 et 3. 

La figure 3 montre des elements du reseau IP 21 de la figure 1, utilises 
dans un mode de realisation de Tinvention. Ce reseau peut comprendre un ou 
plusieurs routeurs 30 pour acheminer les datagrammes IP. Le WLAN 20 
considere ici correspond £ ce qu f on appelle un ESS ("Extended Service Set") 
25 dans le jargon IEEE, c'est-a-dire qu'il s'etend sur les zones de couverture de 
plusieurs AP 22 appartenant au m§me sous-reseau IP. L'APC 23 peut aussi 
jouer un r6le de routeur IP, comme illustre par la figure 2. 

Dans Texemple considere sur la figure 3, le reseau IP 21 permet de 
mettre en liaison le WLAN 20 avec deux UTRAN 15, appartenant par exemple 
30 a deux operateurs cellulaires differents A, B. II y a alors deux RNC 16 
presentant Tinterface /uw vers le meme WLAN. 

Le reseau IP 21 est pourvu d'un serveur DHCP 31 pour assurer 
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rallocation dynamique d'adresses IP a des stations IEEE 802.11 en liaison 
avec les AP 22. Cette allocation dynamique est effective de fagon connue en 
utilisant le protocole DHCP decrit dans la RFC 2131 publiee en mars 1997 par 
PIETF ("Internet Engineering Task Force"). 

5 Le reseau IP 21 est en outre equipe d'un serveur d'authentification 32 

pour effectuer rauthentification des stations IEEE 802.11 conformement a la 
norme IEEE 802. 1X precitee. 

Conformement a I'invention, rauthentification d'un terminal bi-mode 1 8 
est effectuee en deux temps pour lui permettre d'acceder au systeme a travers 
10 un WLAN: d'abord aupres du systeme cellulaire 10 (HLR), puis aupr^s du 
WLAN 20. 

Dans la premiere phase, le terminal 18 dialogue avec le systeme 
cellulaire par I'intermediaire du reseau d'acc^s 15, c'est-S-dire que les 
echanges avec le RNC 16 passent par un node B 17, comme illustre par la 
15 figure 4A. 

Une premiere etape 40 peut consister en I'etablissement d f une 
connexion RRC entre TUE 18 et le RNC 16. Le protocole RRC est decrit en 
detail dans la specification technique 3G TS 25.331, V3.3.0, "RRC Protocol 
Specification" publiee en juin 2000 par le 3GPP. La procedure d'etablissement 
20 de connexion RRC est decrite dans la section 8.1 .3 de cette specification. 

Une fois la connexion RRC etablie, Tetape suivante 41 comporte 
rauthentification du terminal 18 par le reseau coeur 10. 

La fason d'authentifier un terminal UMTS est decrite dans la section 6.3 
de la specification technique 3GTS 33.102, V3.5.0, "Security Architecture", 

25 publiee en juillet 2000 par le 3GPP. Le SGSN 14 interroge d'abord le HLR 11 
en indiquant ridentite (IMSI, "International Mobile Subscriber Identity") du 
terminal 18. La reponse du HLR comprend un ou plusieurs vecteurs 
d'authentification comprenant plusieurs param£tres utiles a rauthentification et 
a Techange de cles de chiffrement avec le terminal. Le SGSN utilise un vecteur 

30 pour tester, le terminal dans un message "Authentification_and_ciphering_ 
request, Le terminal utilise alors les donnees d'abonnement qu'il detient ainsi 
qu'un algorithme d'authentification pour generer une reponse 
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"Authentification_and_ciphering_response" qu'il retourne au SGSN. Celui-ci 
verifie alors ia validite de la reponse par rapport au vecteur utilise pour 
authentifier ou non le terminal 18. 

Cette procedure d'authentification peut etre employee dans divers 
5 contextes de gestion de mobilite faisant intervenir le SGSN (voir section 3.4.2 
de la specification technique 3G TS 24.008, V3.4.1, "Core Network Protocols - 
Stage 3", publiee en juillet 2000 par le 3GPP). Dans I'exemple represents sur 
la figure 4A, le contexte est celui d'une inscription du terminal mobile aupr6s du 
reseau coeur ("IMSI attach"). 

10 De fagon connue, le RNC 16 peut obtenir une liste de caracteristiques 

du terminal mobile 18 ayant etabli la connexion RRC. C'est I'objet de I'etape 42 
indiquee sur la figure 4A. Le RNC interroge le terminal dans un message 
"UE_capability__enquiry\ auquel le terminal repond en indiquant ses 
caracteristiques dans le message "UE__capabilityJnformation" t comme decrit 

15 dans les sections 8.1 .6 et 8.1 .7 de la specification 3G TS 25.331 precitee. 

Les caracteristiques du terminal peuvent aussi avoir ete foumies lors 
de retablissement de la connexion RRC, notamment dans le message 
"Connection_Setup_Complete" de Tetape 40. Dans ce cas, Tetape 42 n'est pas 
necessaire. 

20 Dans le cas qui nous interesse ici, le terminal 18 indique sa capacite 

bi-mode dans le message "Connection_Setup_Complete n ou 
n UE_capabilityJnformation n , de telle sorte que le RNC 16 sait qu'il s'agit d'un 
terminal compatible IEEE 802.1 1 . 

Comme le RNC 16 sait par ailleurs qu'il est relie a un ou plusieurs 
25 WLAN 20 par I'interface luw, il menage la possibility que le terminal 18 accede 
au systeme par I'intermediaire d'un tel WLAN. 

Pour cela, il alloue au terminal bi-mode 18 un jeton d'authentification 
qui permettra £ ce dernier de s'authentifier aupres du WLAN 20. Le jeton 
d'authentification consiste en un mot de passe ou une autre forme de secret 
30 partage. Le RNC le transmet d'une part au terminal bi-mode 18 et d'autre part 
au serveur d'authentification 32. Le jeton d'authentification n'a qu'une validite 
temporaire, fixee par le RNC. 
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La transmission du jeton au terminal 18 peut notamment §tre effectuee 
dans des champs disponibles du message %% Security_modejcommancT du 
protocole RRC (section 8.1.12 de la specification 3G TS 25.331), auquel le 
terminal repond par un message "Security_mode_complete" apres avoir pris en 
5 compte les param&res de securite stipules par le RNC (echange 43 sur la 
figure 4A). 

Le jeton d'authentification est transmis au serveur 32, avec une identite 
du terminal concerne, dans un ou plusieurs datagrammes UDP/IP achemines 
dans le reseau 21. L'identite du terminal peut etre I'lMSI ou de preference le 
10 TMSI ("Temporary Mobile Subscriber Identity") alloue au terminal au cours de 
la procedure description 41 . 

Dans une realisation preferee de Pinvention, le message 
("Security_mode_commancr ou autre) par lequel le RNC 16 fournit le jeton 
d'authentification au terminal 18 comporte egalement les elements 
15 d'information suivants : 

- ESS ID : identifiant du WLAN 20, permettant au terminal de savoir s'il est 
habilite & s'inscrire aupres d'un WLAN donne; 

- IP Subnet Prefix : prefixe de sous-reseau IP utilise dans le WLAN, c'est- 
3-dire que tous les terminaux qui s'y associent obtiennent des adresses 

20 IP commengant par ce prefixe. Ce prefixe permet de connaTtre Tadresse 

IP, de la forme < IP Subnet Prefix > 1 1 1 ... 1 1 1 , employee par le RNC 16 
pour diffuser les informations systeme du BCCH; 

- RNC IP @ : adresse IP du RNC 16 dans le reseau 21, permettant au 
terminal de communiquer avec le RNC a travers le WLAN 20 suivant la 

25 connexion RRC etablie; et 

- Auth. Server IP @ : adresse IP du serveur d'authentification 32, pour que 
le terminal procdde & son authentication au sein du WLAN 20. 

II est possible d'ajouter a ces elements d'information Tadresse IP du 
serveur DHCP 31 auquel le terminal s'adresse pour obtenir une adresse IP 
30 allouee dynamiquement. 

II est A noter que le RNC 16 peut avantageusement tenir compte de la 
localisation du terminal dans PUTRAN 15 pour selectionner les parametres ci- 
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dessus. Par exemple, il pourra designer un WLAN, par le param&re ESS ID, 
lorsque le terminal est en liaison avec un node B 17 proche de la zone de 
couverture de ce WLAN. 

II est egalement possible que le RNC 16 soit relie a plusieurs WLAN, 
auquel cas un ou plusieurs parametres ESS ID sont fournis au terminal en 
fonction de sa localisation. II est notamment possible d'avoir plusieurs 
picocellules WLAN dans une seule macrocellule UMTS (cellule parapluie). Le 
node B peut alors §tre proche de plus d'un WLAN. Gr§ce aux techniques de 
localisation UMTS, le RNC peut connaTtre la position du mobile de maniere 
plus precise que la granularite d'une macrocellule. 

La figure 4B illustre une sequence de messages pouvant intervenir 
pour autoriser I'acces au systeme cellulaire, a travers le WLAN 20, d'un 
terminal bi-mode 1 8 ayant regu un jeton d'authentification. 

La balise radio IEEE 802.11 diffusee par un AP22 inclut I'identifiant 
ESS ID. Lorsque cette balise est captee par le terminal ayant regu cette valeur 
ESS ID avec son jeton d'authentification, il peut proceder a son association 44 
avec TAP puis entamer la procedure d'authentification auprfes du WLAN. 

Comme indique en traits interrompus sur la figure 4B, le terminal est 
d'ores et d6ja en mesure de recevoir les informations systeme du RNC par 
I'intermediaire du WLAN 20, etant donne qu'il a connaissance de Tadresse IP 
sur laquelle celui-ci diffuse le canal BCCH (< IP Subnet Prefix > 1 1 1 ... 1 1 1 ). 

Uauthentification du terminal auprfes du WLAN 20 (etape 45 de la 
figure 4B) est effectuee selon la methode IEEE 802.1X, tfest-a-dire par un 
dialogue entre le terminal 18 et le serveur d'authentification 32 selon le 
protocole EAP, TAP 22 assurant les traductions de format EAPOL / RADIUS. 
La sequence de messages 45 est detaillee sur la figure 4B. 

Lorsque I'authentification est un succfes, Tetape suivante 46 est la 
transaction DHCP entre le terminal 18 et le serveur 31 pourfournir une adresse 
IP dynamique au terminal. 

Une fois qu'il a obtenu cette adresse IP, le terminal peut dialoguer avec 
le RNC 16 sur un canal commun CCCH transpose sur des ports UDP/IP. Dans 
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Pexemple represents sur la figure 4B, ce dialogue 47 consiste en une mise a 
jour de la cellule d'affectation du terminal (procedure "Cell Update" de la 
section 8.3.1 de la specification 3G TS 25.331). 

II est & noter que I'adresse IP du serveur d'authentification 32 peut ne 
5 pas etre transmise explicitement au terminal par le RNC si I'identite d'utilisateur 
employee pour I'authentification IEEE 802.1X est codee au format IMSI-in-NAI, 
c'est-£-dire sous la forme 0IMSI@realm. La raison en est que la partie "realm" 
identifie implicitement le serveur d'authentification. Le terminal 18 peut alors 
s'adresser & un serveur de nom de domaine (DNS, "Domain Name Server") 
10 pour recuperer Padresse IP du serveur 32 avant de proceder a son 
authentification. 

La transmission explicite de cette adresse IP par le RNC presente 
Tavantage de faire I'economie de cette transaction DNS. 

Le procede d'authentification precedemment decrit est applicable dans 
15 le cas general ou plusieurs operateurs UMTS peuvent partager le meme 
WLAN 20, comme dans la configuration illustree par la figure 3. 

Le procede est egalement applicable dans le cas ou le m§me WLAN 
serait implique a la fois dans un schema de couplage etroit et dans un schema 
de couplage faible. Uadresse du serveur d'authentification, ou la partie "realm" 
20 de I'identifiant IMSI-in-NAI, permet alors d'acheminer les messages 
d'authentification vers le serveur adequat (par exemple un serveur local pour le 
couplage etroit et un serveur distant pour le couplage faible). 
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REVENDICATIONS 

1. Procede pour controler I'acces a au moins un systeme cellulaire de 

radiocommunication a travers un reseau local sansfil (20), le systeme cellulaire 
ayant un reseau d'acces radio (15) comportant des stations de base (17) et un 
5 organe de controle (16) auquel est relie ledit reseau sans fil, le procede 
comprenant les etapes suivantes: 

- authentifier un terminal (18) aupres du systeme cellulaire par 
I'intermediaire du reseau d'acces radio; 

- allouer audit terminal un jeton d'authentification; 

10 - transmettre le jeton alloue de I'organe de controle au terminal par 

I'intermediaire du reseau d'acces radio; 

- transmettre le jeton alloue et un identifiant du terminal de I'organe de 
controle a un serveur d'authentification (32) accessible par I'intermediaire 
dudit reseau sans fil; et 

15 - authentifier le terminal aupres du reseau sans fil en verifiant que le 

terminal possede le jeton transmis audit serveur d'authentification. 

2. Procede selon la revendication 1 , dans lequel ('allocation du jeton 
d'authentification est effectuee par I'organe de controle (16). 

3. Procede selon la revendication 2, dans lequel des terminaux 
20 adaptes au systeme cellulaire transmettent chacun une liste respective de 

caracteristiques a I'organe de controle (16), et dans lequel Tallocation d'un 
jeton d'authentification a un terminal (18) authentifie aupres du systeme 
cellulaire est effectuee a condition que la liste transmise par ledit terminal 
indique une capacite d'acces au reseau sans fil (20). 

25 4. Procede selon I'une quelconque des revendications precedentes, 

dans lequel le jeton d'authentification est alloue de maniere temporaire au 
terminal (18). 
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5. Precede selon l'une quelconque des revendications precedentes, 
dans lequel le jeton d'authentification est transmis au terminal (18) avec de 
reformation d'identification se rapportant au reseau local sans fil (20). 

6. Procede selon la revendication 5, dans lequel le reseau local sans fil 
(20) auquel se rapporte ladite information d'identification est selectionne sur la 
base d'une localisation du terminal (18) dans le reseau d'accfes radio (15). 

7. Procede selon Tune quelconque des revendications precedentes, 
dans lequel le reseau sans fil (20) est relie a I'organe de controle (16) £ travers 
un reseau IP (21). 

8. Procede selon la revendication 7, dans lequel le jeton 
d'authentification est transmis au terminal (18) avec de rinformation 
d'adressage dans ledit reseau IP (21 ). 

9. Procede selon la revendication 8, dans lequel ladite information 
d'adressage comporte une adresse de diffusion de sous-reseau IP employee 
par Torgane de contrSle (16) pour diffuser des informations systeme par 
Pintermediaire du reseau local sans fil (20). 

10. Procede selon la revendication 8 ou 9, dans lequel le serveur 
d'authentification (32) est un serveur dudit reseau IP (21), et dans lequel ladite 
information d'adressage comporte une adresse IP du serveur d'authentification. 

11. Procede selon Tune quelconque des revendications 8 a 10, dans 
lequel ladite information d'adressage comporte une adresse IP de Torgane de 
contrdle (16). 

12. Organe de contrfile pour un reseau d'acces radio (15) d'un systeme 
cellulaire de radiocommunication, comprenant: 

- des moyens d'interface avec au moins une station de base (17) du 
systeme cellulaire; 

- des moyens d'interface avec un reseau local sans fil (20); 
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- des moyens d'allocation d'un jeton d'authentification a un terminal (18) 
authentifie aupres du systeme cellulaire par I'intermediaire du reseau 
d'acc^s radio; 

- des moyens de transmission au terminal du jeton alloue par 
5 I'intermediaire du reseau d'acc6s radio; et 

- des moyens de transmission du jeton alloue et d'un identifiant du terminal 
a un serveur d'authentification (32) accessible par I'intermediaire dudit 
reseau sans fil, de telle sorte que le terminal soit authentifie aupr§s du 
reseau sans fil par verification de ce que le terminal possdde le jeton 

10 transmis audit serveur d'authentification. 

13. Organe de controle selon la revendication 12, comprenant des 
moyens pour recevoir une liste respective de caracteristiques d'un terminal 
adapte au systeme cellulaire, et dans lequel les moyens d'allocation d'un jeton 
d'authentification a un terminal (18) authentifie aupres du systeme cellulaire 
sont actives a condition que la liste transmise par ledit terminal indique une 
capacite d'aec^s au reseau sans fil (20). 

14. Organe de contr6le selon la revendication 12 ou 13, dans lequel le 
jeton d'authentification est alloue de maniere temporaire au terminal (18). 

15. Organe de controle selon Tune quelconque des revendications 12 a 
14, dans lequel le jeton d'authentification est transmis au terminal (18) avec de 
Information d'identification se rapportant au reseau local sans fil (20). 

16. Organe de controle selon la revendication 15, dans lequel le reseau 
local sans fil (20) auquel se rapporte ladite information d'identification est 
selectionne sur la base d'une localisation du terminal (18) dans le reseau 

25 d'acc^s radio (15). 

17. Organe de controle selon Tune quelconque des revendications 12 a 
16, dans lequel les moyens d'interface avec le reseau local sans fil (20) 
comprennent une interface IP. 
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18. Organe de controle selon ia revendication 17, dans lequel le jeton 
d'authentification est transmis au terminal (18) avec de ['information 
d'adressage IP. 

19. Organe de controle selon la revendication 18, dans lequel ladite 
5 information d'adressage comporte un prefixe de sous-reseau IP employe pour 

diffuser des informations systeme par I'intermediaire du reseau local sans fil 
(20). 

20. Organe de controle selon la revendication 18 ou 19, dans lequel 
ladite information d'adressage comporte une adresse IP du serveur 

10 d'authentification (32). 

21. Organe de controle selon I'une quelconque des revendications 18 a 
20, dans lequel ladite information d'adressage comporte une adresse IP de 
I'organe de contrSle (16). 
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